REMARKS 



Claims 1-21 are in the application. 

Claims 1-21 are Finally rejected under a new ground of rejection which was not 
precipitated by an amendment by applicant, after a reopening of prosecution subsequent to filing 
of an Appeal Brief. 

It is respectfully submitted that, according to USPTO policies and procedures, the issuing 
of a Final rejection based on new grounds of rejection, not precipitated by action of applicants, is 
improper. MPEP 706.07 provides, in pertinent part: 

706.07 Final Rejection [R-3] 



Before final rejection is in order a clear issue should be developed between the 
examiner and applicant. To bring the prosecution to as speedy conclusion as possible 
and at the same time to deal justly by both the applicant and the public, the invention as 
disclosed and claimed should be thoroughly searched in the first action and the 
references fully applied; and in reply to this action the applicant should amend with a 
view to avoiding all the grounds of rejection and objection. Switching from one subject 
matter to another in the claims presented by applicant in successive amendments, or 
from one set of references to another by the examiner in rejecting in successive actions 
claims of substantially the same subject matter, will alike tend to defeat attaining the 
goal of reaching a clearly defined issue for an early termination, i.e., either an allowance 
of the application or a final rejection. 

While the rules no longer give to an applicant the right to "amend as often as the 
examiner presents new references or reasons for rejection," present practice does 
not sanction hasty and ill-considered final rejections. The applicant who is 
seeking to define his or her invention in claims that will give him or her the patent 
protection to which he or she is justly entitled should receive the cooperation of 
the examiner to that end, and not be prematurely cut off in the prosecution of his 
or her application. But the applicant who dallies in the prosecution of his or her 
application, resorting to technical or other obvious subterfuges in order to keep the 
application pending before the primary examiner, can no longer find a refuge in the 
rules to ward off a final rejection. 

The examiner should never lose sight of the fact that in every case the applicant 
is entitled to a full and fair hearing, and that a clear issue between applicant and 
examiner should be developed, if possible, before appeal. However, it is to the 
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interest of the applicants as a class as well as to that of the public that prosecution of 
an application be confined to as few actions as is consistent with a thorough 
consideration of its merits. 

Neither the statutes nor the Rules of Practice confer any right on an applicant to an 
extended prosecution; Ex parte Hoogendam, 1939 CD. 3, 499 O.G.3, 40 USPQ 389 
(Comm'r Pat. 1939). 



706.07(a) Final Rejection, When Proper on Second Action [R-6] 

Due to the change in practice as affecting final rejections, older decisions on questions 
of prematureness of final rejection or admission of subsequent amendments do not 
necessarily reflect present practice. 

Under present practice, second or any subsequent actions on the merits shall be final, 
except where the examiner introduces a new ground of rejection that is neither 
necessitated by applicant's amendment of the claims , nor based on information 
submitted in an information disclosure statement filed during the period set forth in 37 
CFR 1.97(c) with the fee set forth in 37 CFR 1.17(p). Where information is submitted in 
an information disclosure statement during the period set forth in 37 CFR 1.97(c) with a 
fee, the examiner may use the information submitted, e.g., a printed publication or 
evidence of public use, and make the next Office action final whether or not the claims 
have been amended, provided that no other new ground of rejection which was 
not necessitated by amendment to the claims is introduced by the examiner . See 
MPEP § 609.04(b) 



In the consideration of claims in an amended case where no attempt is made to point 
out the patentable novelty, the examiner should be on guard not to allow such claims. 
See MPEP § 714.04. The claims may be finally rejected if, in the opinion of the 
examiner, they are clearly open to rejection on grounds of record. 

* * * 

In this case, the Examiner has refused to permit consideration of amendments which 
might have avoided contention on the new ground of rejection, in a manner which would not 
have altered consideration or application of the prior art, and has truncated opportunity to 
interview the case to resolve further issues. Therefore, withdrawal of the Finality of rejection is 
respectfully requested. 
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REJECTION UNDER 35 U.S.C. § 112, FIRST PARAGRAPH 
Claims 1-21 are rejected under 35 U.S.C. § 1 12, first paragraph, as allegedly failing to 
comply with the written description requirement, and in particular, the use of the phrase "or a 
normal browser is to be employed" in claim 1, "or whether an insecure browser is to be 
employed" in claim 9. 

In the application as filed, claims 1 and 9 stated: 

1 . A secure user interface method, for interacting with a user through a 
browser, comprising: 

controlling the browser to request a document from a cooperative server, the 
browser providing data export support functionality; 

receiving data with the browser in response to the request; 

automatically determining, based on a type encoding of the received data, 
whether a secure browser is to be employed, the secure browser having a set of 
functionality restricted with respect to a normal browser, to enhance security of a 
received document against data export; 

receiving the secure content for presentation in the secure browser; and 

communicating an input from the user, through the secure browser, to a 
cooperative server. 

9. A secure user interface method, for interacting with a user through a 
browser, the browser providing a set of navigational functionality, comprising: 

requesting a document from a cooperative server; 

receiving data in response to the request; 

automatically determining whether a secure browser is required to be employed 
by a content provider, the secure browser restricting interaction of the user with tasks 
other than those permitted by the secure browser; 

invoking the secure browser; 

receiving the secure content for presentation in the secure browser; and 
communicating an input from the user, through the secure browser, to a 
cooperative server. 
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As such, these claims alone provide "written description" of the invention, and antecedent 
basis for the claim language now employed. 

Figs. 1 and 2 also clearly show the process for invocation of a secure browser, and the 
"data encoding type" or "data type encoding" as a basis for selecting the secure browser. See 
especially Fig. 2, "Content includes triggering link to secure content" and "QSB delivers secure 
content". 

The specification includes an Appendix which includes operative code which implements 
various portions of the method, demonstrating authentication of the secure browser and launch of 
the secure browser (an error message of the launch is failed). 

As basic "written description" for a "normal browser", "secure browser" and an "insecure 

browser" is found in at least the following passages, which state: 
Page 1, line 8: 

BACKGROUND OF THE INVENTION 

Secure browsers are designed to provide a secure environment to deliver valuable 
content and assessments such as tests and exams. Web servers can deliver questions 
to any web browser, but most browsers are designed to be as open and flexible as 
possible. When you are delivering secure content or assessments online you need far 
more security than most browsers provide. 

With a secure browser, a content provider can specify that secure content such as a 
test or an exam may only be delivered in such manner as to significantly reduce the 
likelihood of cheating, or inappropriate disclosure of sensitive content. 
Secure browsers allow a content provider to prevent users from printing questions, 
using the right-click on the mouse, saving the HTML, viewing the source, and 
accidentally exiting an assessment in a proctored environment. The look and feel of 
the screen displayed may otherwise correspond to that of a normal browser, except 
pages may not be stored (cached) in the history, and certain menu options and icons 
are not displayed or are made unavailable. 

Web browsers are typically flexible and open programs which aid the user in navigating 
the Internet, running programs or applets, and giving the user full control over what 
he/she is doing. But when browsers are used to take assessments, it's desirable that 
the user should not have full control and open access. Since the assessment is 
designed to measure knowledge or a skill, and sometimes has consequences for 
passing or failing, it's desirable that what the user can do is restricted; essentially the 
user should only take the assessment and not be able to perform other tasks. For 
example, it can be desirable that users should not be able to navigate the Internet 
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(where they might find right answers), communicate with others, run other programs, 
print the screen or copy the questions to other people and so on. 

This need has given rise to "secure browsers" or "locked down browsers" or "kiosk 
software", which are versions of standard browsers which limit the functions that the 
user can perform. Computers which are used to deliver assessments therefore typically 
have secure browsers installed, and these lock down the computers to prevent 
unauthorized actions while taking an assessment. 

These secure browsers fulfill needs in situations where users take assessments on their 
own. But very often assessments are mixed in with other uses of the computer. For 
example, a learning management system might accept a student's login and allow him 
or her to choose an assessment; a student might undertake some online course (where 
they are allowed free use of their browser) followed by an assessment (where they are 
not); or a corporate executive might use their corporation's intranet, and then be 
scheduled for a business rules or product knowledge or safety regulation exam. 
Therefore, other secure browser products such as the Vantage Vanguard™ 3.0 secure 
desktop environment, Questionmark's own, prior Perception Secure Browser product, 
or Software Secure's Securexam Browser lack this flexibility, making full use of the 
computer in both secure and insecure modes difficult. Other secure browsers need to 
be specifically launched to take the assessment; they cannot be launched on demand 
by an ordinary browser, when secure content delivery is required. 

In such mixed scenarios, it would be desirable to have a browser which can become 
secure when an assessment (or other secure content) is started and then become open 
again when an assessment (or the secure content) is finished. 

Essentially the problem may be stated that it is desired that secure content to be called 
from insecure content, with the secure content run securely. Likewise, it is desired that 
an open user environment be triggered into a restricted user environment, with some 
assurance that the restricted conditions be maintained. 

See also, p. 5, line 26: 

The look and feel of the screen displayed may be very similar to that of a normal 
browser, such as Internet Explorer, although the pages are not stored in Internet 
Explorer's history listing, and some navigation buttons and toolbars are usually omitted. 
Likewise, various components of a host browser or operating system may be employed 
for content presentation, rendering, and use. 

The method of the invention is also clearly described in the specification. For example, 

Page 10, line 11: 

Launch of a secure browser from a regular browser 

Internet technologies allow a MIME type to be specified to indicate to the computer 
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operating system which program should be used to display the content. The MIME type 
may be defined by the file extension or the Content-type header returned by a web 
server. The present invention, for example, specifies a new MIME type of 
"Questionmark Secure Browser" (or equivalent) which starts the secure browser to 
display the assessment or e-learning content that requires more security than a normal 
browser would provide. 

A web page contains a link (triggering link) that, when accessed, passes a MIME type to 
indicate that a secure browser is required to display this content. 

Indicating which web page to 'get' 

While the MIME type specifies that the content must be displayed in a secure browser, 
it doesn't specify where the content is located. There are three general alternatives: 
(1 ) Allow the original link to specify the URL or the content so that the secure browser 
can call the content using a normal http GET command; (2) Allow the secure browser to 
have a system configuration that allows the secure browser to be triggered to call a 
specific URL or IP address; and (3) Allow the secure browser to have a system 
configuration that allows the secure browser to be trigged to call a specific URL or IP 
address along with a parameter that was provided as part of the trigger (combining (1 ) 
and (2), above - the server URL/IP address is configured within the secure browser 
while the specific assessment and other details is defined in the trigger). It's also 
possible to have the cooperating server provide some of the details. 

Page 11, line 25: 

It is therefore an object of the invention to provide a secure user interface method, for 
interacting with a user through a browser, the browser providing a set of navigational 
functionality, comprising requesting a document from a cooperative server; receiving 
data in response to the request; automatically determining whether a secure browser is 
required to be employed, for example based on a type code or type encoding, the 
secure browser defining a set of functionality restricted with respect to the functionality 
of the browser alone; invoking the secure browser; receiving the secure content for 
presentation in the secure browser; and communicating an input from the user, through 
the secure browser, to a cooperative server. The functionality may be limited 
navigational functionality (e.g., access of unrestricted documents, documents outside a 
specified set, or access of other applications or windows), data manipulation 
functionality, data export functionality (e.g., print, copy, save, cut, paste, etc.), or the 
like. The server may authenticate the secure browser, and likewise, the secure browser 
may authenticate the server, before presenting the secure content. The secure 
browser may restrict termination of its own execution. 

Page 13, line 8: 

According to the present invention, the secure browser may still use basic internet 
technologies (http, html, MIME types, etc) to ease deployment issues; launch a secure 
browser from a normal browser; be initiated by a triggering link; and employ secure 
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browser calls back to gather actual content. 
Example 1 

According to a first embodiment of the invention, a communication steam is provided 
between a user's computer and a server, exemplified as follows by sample HTTP 
headers. This interaction is represented in Fig. 1 . 

Headers sent when browser calls web server 

GET /q/open.dll HTTP/1.0 
Accept: */* 

Accept-Language : en-gb 
Pragma: no-cache 

User-Agent: Mozilla/4 . 0 (compatible; MSIE 6.0; Windows NT 
5.0; . NET CLR 1.0.3 705) 
Host: localhost 

Headers sent when web server responds to browser 

HTTP/1.1 200 OK 

Server: Microsof t-IIS/5 . 0 

Date: Wed, 14 May 2003 15:03:58 GMT 

Content-Type: text/html 

Secure browser headers 

Possible example headers sent when web server responds to browser calling the 
'trigger'; note MIME type qmsb. 

HTTP/1.1 200 OK 

Server: Microsof t-IIS/5 . 0 

Date: Wed, 14 May 2003 15:03:58 GMT 

Content-Type: applicat ion/qmsb 

Possible example headers sent by secure browser when calling server; note security 
code which is passed from secure browser to web server: 

GET /q/open.dll HTTP/1.0 
Accept: */* 

Accept-Language: en-gb 
Pragma: no-cache 
User-Agent: Secure Browser 

Security-Code: 4 7bce5c7 4f 58 9f 486 7dbd5 7e9ca9f 808 
Security-Expires :15:05:20 03:03:25 
Host: localhost 

Page 15, line 14: 

The URL to QSBIaunch is, for example, www.xyz.com/qsblaunch.asp and the URL to 
QSBcheck is www.xyz.com/qsbcheck.asp. 
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Triggering link 

The triggering link consists of the URL to QSBIaunch, followed by arbitrary parameters. 
The parameters will typically define the assessment to be run. All parameters must be 
URL encoded in the usual way. 

Example triggering links: 

www.xyz.com/qsblaunch.asp?Assessment=12345&Group=Potato 
www.xyz.com/qsblaunch. asp?Token=1 2345678901 234 

What QSBIaunch does 

• QSBIaunch does the following: 

• It receives on the command line the parameters 

• It knows the URL of the QSBcheck.asp or similar program. 

• It calls QS Server technologies (QSBst.dll) to pass the url and parameters and 
gets back a checksum. 

• It then constructs a dynamic .qmsb document containing the URL, parameters, 
version and checksum. 

• This .qmsb document is itself encrypted to ensure that QS only will run from an 
approved source 

• It sends it back to the browser with content type .qmsb. ASP code to do this is as 
follows: Response. ContentType = "application/x-qmsb" 

Response. AddHeader "Content-Disposition", "filename=qsblaunch.qmsb" 

The QMSB file will contain a message at the top in case it is read in error, for example,: 
"If you are reading this file, then there has been an error in installing the 
Questionmark Secure. You need to install Questionmark Secure from <url> and 
you need to set up your browser to call Questionmark Secure on the MIME type 
of application/x-qmsb." 

What happens at the client end after QSBIaunch runs 

QSBIaunch sends back a document, which is of MIME type, associated with QSB. 

If Questionmark Secure Browser is not installed, there is no way that the participant can 
proceed. They have to install Questionmark Secure Browser and re-run the triggering 
link. Or it may be possible to have the server deliver a message to the user telling them 
where to install it, or helping them automatically do so. 

When QS is installed, the install program will configure QS as being associated with the 
MIME type above. This will automatically ensure that IE 5+ associates the type with QS. 
The install program may also attempt to configure Netscape to treat QSB as a helper 
application for this MIME type, or identify and configure other browsers to properly view 
QSBdocuments. 

If the user's browser is not configured to run QS, then the user may be asked if they 
want to save or open the file. Of course, the server will not deliver secure content in 
such a circumstance, since the secure browser is not operative to generate an 
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anticipated response. Even if the user's computer system is configured to run QS, they 
may have to confirm that they want to. Provided the user's browser is set correctly, this 
will call QS to run the document. 

QS then: 

• Checks the checksum within the QMSB file is valid. If not, it refuses to run, and 
generates a message 

• Checks the version within the QMSB file, and if the version is greater than 
supported by the QSB, refuses to run, saying that it needs to be upgraded 

• Constructs a call to QSBcheck, using the URL in the file 

• Includes the parameters 

• Includes a checksum in the HTTP header for QSBcheck to check 

Page 21, line 1: 

Example 4 

A Learning Management System (LMS) is a web-based software program that 
manages how learners access electronic and class-based learning. Commonly a 
participant logs into an LMS in a browser and then is able to take courses, assessments 
and be directed to appropriate places that allow learning and/or assessment to take 
place. 

LMSs can call assessments using a variety of protocols including a standard 
promulgated by the AICC called AICC HACP, a specification promulgated by ADL 
SCORM called the SCORM 1.2 Runtime Environment and proprietary protocols. LMSs 
can make calls to Questionmark Perception via any of these means using a protocol 
called Perception Integration Protocol (PIP). 

The use of PIP is controlled by an ASCII PIP file on the Perception Server, which 
defines what sort of interaction from the LMS is permitted. It's possible to define that 
Questionmark Secure (a secure browser) is popped up from the LMS by making this 
setting in a PIP file. For example the following PIP file makes all calls from an LMS via 
this PIP file call Questionmark Secure and it also arranges that the Home button at the 
end of assessment closes the secure browser. 

; qsTest.pip 

; demonstrates invoking Questionmark Secure 

; sets Home button to close QS at end 

; call with session . dll ?call=qsTest &NAME=<your_name> 

; September 2 0 03 

[Input] 
NAME=NAME 
GROUP="Testing" 
DETAILS="Questionmark Secure" 

; amend session to match assessment ID on your system 
SESSION=" 744656 9 86 858 7320" 
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[Settings] 
UseNotif y=no 
Require QS=yes 
UseHome=yes 

Home= javascript : SB_ExitQS ( ) ; 

Using a PIP file like this, it means that users of corporate LMSs from companies like Saba, 
Plateau, Docent, Thinq, or academic course management systems like Blackboard and 
WebCT, can invoke a secure browser without making any change to the LMS. Providing 
they can call Perception via one of the supported protocols via PIP, then a secure browser 
can come up when the assessment is taken - the participant uses an ordinary browser to 
run the LMS and then a secure browser to take the assessment. 

It is therefore respectfully submitted that the application has ample support for the claim 
language, including a proper written description, to the extent that any such independent 
requirement exists under 35 U.S.C. § 1 12. Further, it is also clear that the claims are supported 
by an enabling specification and disclosure. Finally, the claims are definite, and lack ambiguity 
as to the scope of protection sought or its interpretation. The scope of the claims is also 
reasonably curtailed with respect to the scope of the disclosure. 

Therefore, it is respectfully submitted that all rejections under 35 U.S.C. § 112 be 
withdrawn. 



REJECTION UNDER 35 U.S.C. 102(e)/103(a) 

Claims 1-4 and 6-20 are rejected as being anticipated under 35 U.S.C. § 102(e) over 
Winneg et al., US 7,069,586. Claims 5 and 21 are rejected as being obvious under 35 U.S.C. § 
103(a) over Winneg et al., US 7,069,586 as applied to claims 1 and 9, respectively, in view of 
Chang et al, US 2002/0097416. 

Claims 1 and 9 provide, respectively: 



QMark-201.2 



- 11- 



1 . A secure user interface method, for interacting with a user through a browser, 
comprising: 

controlling the browser to request a document from a cooperative server, the browser 
providing data export support functionality; 

receiving data with the browser in response to the request; 

automatically determining, based on a received data encoding type, whether a secure 
browser or a normal browser is to be employed, the secure browser having a set of functionality 
restricted with respect to the normal browser, to enhance security of a received document against 
data export; 

receiving the secure content for presentation in the secure browser; and 
communicating an input from the user, through the secure browser, to a cooperative 

server. 

9. A secure user interface method, for interacting with a user through a browser, the 
browser providing a set of navigational functionality, comprising: 
requesting a document from a cooperative server; 
receiving data in response to the request; 

automatically determining, based on a received data type encoding, whether a secure 
browser is required to be employed by a content provider or whether an insecure browser is to be 
employed, the secure browser restricting interaction of the user with tasks other than those 
permitted by the secure browser which are permitted by the insecure browser; 

invoking the secure browser; 

receiving the secure content for presentation in the secure browser; and 
communicating an input from the user, through the secure browser, to a cooperative 

server. 

Winneg et al. is respectfully distinguished in that the secure application is invoked based 
on an identification and login credentials of a user which have nothing whatsoever to do with any 
"received data encoding type" (claim 1) or "received data type encoding" (claim 9), and the 
secure application is used to retrieve the protected content regardless of any such data encoding 
type or data type encoding. 

The word "encoding" means, for example: 

The way in which symbols are mapped onto bytes, e.g. in the rendering of a particular 
font, or in the mapping from keyboard input into visual text; A conversion of plain text 
into a code or cypher form (for decoding by the recipient) 

eo,wiktionary.org/wiki/encoding 
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While this definition is not per se binding on the examiner, it is informative, and clearly 
inconsistent with the examiner's interpretation, which encompasses something different. In 
particular, as "user type" is clearly distinct and non-overlapping with an "data encoding type" or 
a "data type encoding". In order to defend and maintain this interpretation, the examiner should 
provide competent evidence of a definition of the phrases at issue which clearly encompass 
Winneg et al., or it should be withdrawn. 

This difference can be clearly seen in the passage at Col. 25, line 52-Col 26, line 10: 

The exam creation module may enable users (e.g., instructions or professors) to create 
an exam and an encrypt the exam for later use by an exam-taking application. The 
exam creation module may provide users one or more options for the format of an 
exam. The exam creation module may provide a first option of creating an exam that 
does not include any exam content (i.e., questions), which may be considered a 
"bluebook" type of exam. The exam creation module also may provide the option of 
creating an exam that includes exam content (i.e., questions). Before running the exam 
creation module, a user (e.g., a professor, instructor or teaching assistant) may create 
an exam content file by using a word processing application such as Microsoft Word. 
The exam creation module then may be used to provide a password for and/or encrypt 
the exam content file. 

In a first act, the user may be prompted to enter the user's ID and password. 

In a next act, the exam creation module may enable the user to locate the exam 
content file, for example, by enabling use of a browser application. 

In a next act, the user may be prompted to enter a password that any students who will 
take the exam will be required to enter in order to take the exam and access the exam 
content file. The password and exam content then may be saved together in the exam 
content file. 

As will be apparent, the Winneg et al. application and method defines the content and 
sources of information which are available only after login, and it is not any "received data 
encoding type" or "received data type encoding" which controls restrictions on functionality. 
Even if there are restrictions selective for particular exams, there is no teaching or suggestion that 
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these restrictions are encoded in or as part of the document requested, but rather these are 

provided as set-up information for the secure application (Col. 17): 

Returning to method 140, in a next Act 144, any instances of the first application 
currently executing on the computer system may be terminated. As described above, 
the first application should be included on a list of authorized processes, else the first 
application would be terminated by performance of Acts 302 308 described below. 
However, prior to performance of method 300, one or more instances of the first 
application already may be executing on the computer system, and may be accessing 
unauthorized content and/or executing unauthorized processes. 

Accordingly, prior to performance of Act 146, any instances of the first application 
currently executing on the computer system may be terminated. To determine if an 
instance of the first application is currently executing on the computer system, a list of 
processes currently executing on the computer system may be accessed. The list may 
contain one or more entries, where each entry contains an identifier of a process 
currently executing on the computer system. Each entry may be accessed to determine 
whether the identifier of the entry is an identifier for the first application. If a match is 
found, the instance of the first application may be terminated and the identification of 
the instance may be removed from the list of currently executing processes. 

Winneg et al. thus disclose that a secure application (which may include a secure 

browser) is invoked, having predetermined restrictions, and then a request for content is issued, 

within the secure application, which does not change in dependence on the content itself or a 

respective content encoding. Different users can have different usage restrictions with respect to 

the same content — some users are test creators, some are test graders, some are test takers. Since 

the same content is treated differently, it clearly cannot be the content which controls the 

restrictions. 

These restrictions are therefore based on the user login and the content to be retrieved, 
and such restrictions precede the content retrieval, are not established after the content is 
retrieved based on its encoding. 

It is not disputed that Winneg et al. disclose a secure application. However, the 
disclosure of Winneg et al. is somewhat specific for an application which modifies the operating 
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system environment, and Winneg et al. is not enabling in its description of how an invokable 



browser could perform the stated functions. Indeed, column 16 seems to indicate that the secure 
application is itself not a browser, stating: 

Further, the first application may be configured such that hyperlink functionality is not 
available within the first application. Thus, a user cannot type in a uniform resource 
locator (URL) and automatically launch a browser application that hyperlinks the user 
outside of the first application. 

Likewise, Col. 19 states: 

If Act 306 includes both looping through an authorized process list and looping through 
an unauthorized process list, the unauthorized process list may function as an added 
security measure. The unauthorized process list may include one or more processes 
that a controlling entity is particularly concerned about executing during execution of the 
first application. For example, the unauthorized process list may include browser 
applications, (e.g., Microsoft Internet Explorer), applications for scheduling tasks to be 
performed on the computer system, (e.g., Microsoft Task Scheduler), and applications 
for managing tasks performed on the computer system, (e.g., Microsoft Task Manager). 
Terminating task-managing manager and task-scheduling applications prevents a 
process (e.g., an application) that has been scheduled to execute during execution of 
the first application from executing. 

Further supporting disclosure in Winneg et al. is as follows: 

Col. 6: 

DESCRIPTION 

An illustrative embodiment of a method of securely executing an application such that 
unauthorized content is prohibited from being either accessed or viewed by a user of 
the computer system during execution of the application is described below in the 
context of executing an exam-taking application. Such an illustrative embodiment is not 
meant to limit the scope of any of the claims set forth below and is provided merely for 
illustrative purposes, as such method may be used in a variety of other contexts, for 
example, in the context of executing a browser application. 

As used herein, an "exam-taking application" is an application configured to enable a 
user to use a computer system to provide one or more answers to one or more 
questions of an exam. 

In Act 102 it may be determined whether execution of this exam-management 
application is the result of the computer system being rebooted during an exam-taking 
application. 
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For example, as described below in relation to Act 159, the computer system may be 
configured such that, if the computer system is rebooted, execution of the exam-taking 
application is re-initiated. For example, in Act 159 of FIG. 8, a computer system 
parameter (i.e., flag) may be changed from its default value such that upon booting the 
computer system, the student exam-management application is automatically 
initiated.... 

Accordingly, as a result of the computer system being booted, such key may be 
accessed, to determine if the student exam-management application should be 
initiated. 

Further, as described below in relation to Act 224 of FIG. 14, as a result of exiting the 
exam-taking application, the computer system parameter (e.g., auto-run key) may be 
set back to its original default value so that the exam management application is not 
initiated upon reboot. 

Thus, Act 102 may include ascertaining whether this auto-run key is set to a logical 
value indicating that execution of the exam-management application is the result of the 
computer system being rebooted during an exam-taking application. 

Col. 8: 

If, in Act 108, it is determined that the login is successful because the entered student 
ID and the entered student password are both valid, then, in Act 112, the user may be 
enabled to select an action from two or more actions corresponding to exams. For 
example, Act 1 12 may include providing a GUI that displays a menu from which a user 
may select an action from two or more actions corresponding to exams. 

For example, Act 1 1 2 may include providing the GUI illustrated in FIG. 4. This GUI 
provides a user with the option of taking an exam, deleting prior exams or copying a 
prior exam to a diskette. 

In a next Act 1 14, it may be determined whether the user selected to copy an exam file, 
for example, by selecting the appropriate radio button from the GUI of FIG. 4. 

If the user selected to copy an exam file in Act 114, then, in Act 116, the user may be 
enabled to copy an exam file. 

Act 1 1 6 may include enabling a student to copy an exam from an exam directory to 
another location, for example, a floppy disk or another network address. This enables 
the student to make copies of an examination that can be attached to an email, stored 
as a backup or sent to a network directory corresponding to a course for which the 
exam was taken. As described below, upon completion of an exam, an exam file 
containing the student's responses to the exam questions may be stored in a 
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predefined directory. Accordingly, Act 1 16 may include accessing such predefined 
directory and selecting an exam to copy to another location. 

Col. 10 

FIG. 8 is a flowchart illustrating an example of a method 130 securely executing an 
exam-taking application such that a user is prohibited from accessing or viewing 
unauthorized content during execution of the exam-taking application. 

In Act 141 , any capabilities provided by the computer system by which a user of the 
computer system may access or view unauthorized content may be disabled. Disabling 
such capabilities may be accomplished using any of a variety of techniques. 

Col. 13: 

Accordingly, Act 21 0 may include providing a dynamic link library (DLL) that includes a 
plurality of hooks for intercepting events (e.g., messages, mouse action, key strokes) 
before they reach an application, for example, the first application described in more 
detail below. Further, one or more of the hooks of the DLL may be configured to 
prevent the event from reaching the first application, before performing an action before 
sending the event to the application. 

Thus, Act 210 may include installing such a DLL on the computer system such that one 
or more of the hooks may be utilized during execution of the exam-taking application. 

Appendix III is an example of a DLL, Hooksdll.C written in the C programming language 
that may be installed as part of Act 210 and whose hooks may be utilized during 
execution of the first application described below. Other processes written in other 
programming languages or a combination of one or more programming languages, 
including C, may be used as part of Act 21 0 to implement programming hooks that 
prevent unauthorized content from being accessed by or displayed by the first 
application. 

The DLL for providing the hooks (hereinafter Hooksdll) may include a function to assign 
a value to a variable of the computer system, where this variable may be accessed by 
other functions to determine that HooksDII has been installed and initialized. 

Col. 14: 

Accordingly, Hooksdll also may include a function to intercept a message sent from the 
OS to the first application that responds to a user hitting the "Ctrl" and the "T" keys 
concurrently, and sending a message to the first application to display the timer. 

Hooksdll also may include a function to intercept all messages sent from the OS to a 
destination window (e.g., a window of first application) in response to a user hitting a 
key or combination of keys of the keyboard. A return value for this hook may be set to a 
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non-zero value to disable certain key combinations. For example, this hook may be 
used to disable function keys F1 F10, to disable ALT_SHIFT DLL, any of the hook keys 
listed below in Table 1 , or any of a variety of other keys or key combinations. 

Hooksdll also may include a hook to intercept any messages from the operating system 
to a destination window (e.g., a window of the first application) in response to a mouse 
event, for example, double clicking the left mouse button, right clicking the right mouse 
button, or moving the scroll wheel of the mouse. This hook may be configured to return 
a non-zero value such that the mouse message is not sent to the destination window. 
Further, the hook may be configured to determine the mouse position and, based on 
the mouse position, disable one or more mouse events. For example, this hook may be 
used to disable one or more of the mouse events listed below in Table 2. 

Col. 22: 

In a next Act 1 58, the exam file may be opened by the first application so that the exam 
may begin. In other words, the student may be enabled to enter one or more responses 
to one or more questions of the examination. 

In a following Act 182, the one or more unauthorized processes terminated before 
execution of the first application may be initiated. For example, the list of terminated 
processes described above in relation to Act 208 may be accessed and each process 
in the list may be initiated. Thus, if a user had several applications, for example, an 
email application and a browser application executing before execution of the exam- 
taking application began, these applications will be initiated so that the user's computer 
system is returned to the state that it was in before the user executed the exam-taking 
application. 

Therefore, it is clear that Winneg et al. employ a materially different method. For 
example, with respect of claim 1, the application of Winneg et al. which requests a document 
does not perform the step of "automatically determining, based on a received data encoding type, 
whether a secure browser or a normal browser is to be employed, the secure browser having a set 
of functionality restricted with respect to the normal browser, to enhance security of a received 
document against data export". Likewise, Winneg et al. doe not perform the step of 
"automatically determining, based on a received data type encoding, whether a secure browser is 
required to be employed by a content provider or whether an insecure browser is to be employed, 
the secure browser restricting interaction of the user with tasks other than those permitted by the 
secure browser which are permitted by the insecure browser". This decision is made based on a 
user login, and independent of the "data encoding type" or "data type encoding". 
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Winneg et al. is thus respectfully distinguished in that a "professor" and a "student" can 
access the very same document (having the same data type encoding or data encoding type) and 
be afforded different privileges based on their login; in accordance with the presently claimed 
invention, it is the data which determines the browser as being "normal" or "insecure" on one 
hamd, or "secure" on the other, not the user , which in turn defines the set of privileges available 
through the selected browser. 

In formulating the rejection, the Examiner cites various portions of Winneg et al, which 
it is respectfully submitted do not teach or suggest at least the foregoing limitation. For example, 
the Examiner cites Col. 4, lines 3-5. However, at this passage, Winneg et al. state: "The 
application being securely executed may be of any of a variety of types of applications, for 
example, a browser application or an application for receiving answers to questions of an 
examination (i.e., an exam taking application)." Thus, while Winneg et al. appear to disclose a 
secure application, it fails to disclose that a normal or insecure browser is also selectively 
available, in dependence on a data type encoding or data encoding type. 

The secure mode of Winneg appears to be initiated based on a boot sequence, operating 
system limitation or user login. Col. 6, lines 35-67. Col. 9, lines 45-47, 50-55 and Col. 10, lines 
10-13 indicate that a user input (and not a data type encoding or data encoding type) determines 
which application to initiate. ("For example, FIG. 7 illustrates a GUI that may be displayed to a 
user to determine which application to initiate for the exam." "After the user has entered the class 
name and the professor in their respective fields and clicked on the OK button, the exam- taking 
application may use this information to determine a first application to be executed so that the 
student may take the exam (i.e., provide responses to one or more questions) and to determine the 
content (e.g., the questions of the exam or material to assist the user in taking the exam), if any, 
to be displayed by the first application." "Else, after hitting the 'OK' button of the GUI, next, in 
Act 122, secure execution of the exam-taking application may be initiated."). 

Winneg et al. appear to provide a system in which a local software application controls 
the client computer independent of a data type encoding or data encoding type. For example, 
Col. 6, lines 35-48 describe a system which defaults to a "secure" mode, and is machine status 
dependent, not received data encoding type or data type encoding dependent. Indeed, the 
authorization to access or delete an exam is provided within the "secure" mode, and thus these 
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functions are all provided within a single application. Therefore, the decisions 114, 1 16 do not 
serve to switch different "browsers" which are normal/insecure and secure. Col. 8, lines 48- Col. 
9, line 44. Throughout the entire exam process, the machine is locked in a "secure" mode, 
maintaining this mode apparently independent of data and its associated type encoding or 
encoding type. 

CLAIMS 1-8 

The examiner interprets the phrase "data encoding type" in claim 1 to encompass a login 
classification of the user. This, however, is an erroneous interpretation of the claim. The 
complete claim phrase of claim 1 is ". . .based on a received data encoding type . . ." Therefore, 
this language does not relate to a type of USER , but rather an encoding type of DATA . 
Likewise, the result of this encoding type in accordance with the claims is the selection of a 
secure browser or a normal browser, with respectively different level of functionality, and not a 
set of privileges of the user within a singular application. It is especially noted that, in 
accordance with claim 1, the decision of whether to employ a secure browser or a normal 
browser is automatically determined based on an encoding type of the received data. Therefore, 
it is not the server, but the respective client, which automatically determines whether a normal 
browser or a secure browser is to be employed. 

Col. 9, lines 59-67 provide that it is the information entered in the fields of Fig. 7 that are 
used to determine if content is to be displayed by "the first application" (e.g., MS Word). Fig. 7 
shows a login screen, in which a user enters class name, professor and exam date. This does not 
correspond to the document requested by the browser from the cooperative server, and received 
by the browser in response to the request, as provided by claim 1 . 

Therefore, it is seen that Winneg et al. employ a presumption that, so long as the exam- 
taking application is engaged, the machine must be in the "secure" mode, and do not employ data 
encoding type received from the server to automatically control whether a secure browser or 
normal browser is employed. 

The dependent claims 2-4 and 6-8 are believed to be distinguished at least on the same 

basis. 

CLAIMS 9-20 
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The examiner interprets the phrase "type encoding" in claim 9 to encompass a login 
classification of the user. This, however, is an erroneous interpretation of the claim. The 
complete claim phrase of claim 9 is "automatically determining, based on a received data type 
encoding, whether a secure browser is required to be employed by a content provider or whether 
an insecure browser is to be employed, the secure browser restricting interaction of the user with 
tasks other than those permitted by the secure browser which are permitted by the insecure 
browser". 

Therefore, this language does not relate to a type of USER , but rather a type encoding of 
DATA . Likewise, the result of this type encoding in accordance with the claims is the selection 
of a secure browser or an insecure browser with respectively different level of functionality, and 
not a set of privileges of the user within a singular application. 

It is especially noted that, in accordance with claim 9, the decision of whether to employ a 
secure browser or a normal browser is automatically determined based on a type encoding of the 
received data. Therefore, it is not the server, but the respective client, which automatically 
determines whether a secure or insecure browser is to be employed, and that this determination is 
automatically made based on a type encoding of the data received by the browser. 

Therefore, it is seen that Winneg et al. employ a presumption that, so long as the exam- 
taking application is engaged, the machine must be in the "secure" mode, and do not employ type 
encoding of requested data received from the server to automatically control whether a secure 
browser or insecure browser is employed. This differs from the present invention in accordance 
with claim 9, which permits, for example, the server to dynamically control the browser based on 
data type encoding. 

Claim 9 is particularly distinguished in that Winneg et al. employ only a single 
application type, and not both a separately defined secure browser and an insecure browser, the 
use of which is determined automatically based on a data type encoding. As discussed above, the 
decision by Winneg et al. of whether to employ security or not is made in dependence on a login 
status, and therefore, Winneg et al. do not teach or suggest the claimed invention of claim 9. 

The dependent claims 10-20 are believed to be distinguished at least on the same basis. 
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It is particularly noted that claims 15 and 16 make the distinctions more explicit, and to 
the extent that the Examiner does not agree with Applicants' arguments regarding claim 9, a 
separate finding must be made with respect to claims 15 and 16, which provide: 

1 5. The user interface method according to claim 9, wherein the secure 
browser is initiated based on a type encoding of the received data. 

1 6. The user interface method according to claim 9, wherein the secure 
browser is initiated based on a code associated with the secure content. 

Thus, claim 15 makes clear that "the secure browser is initiated based on a type encoding 
of the received data," which is the same data that was requested, and is this clearly not open to an 
interpretation that some different data, such as the user login information which is provided 
FROM the browser TO the cooperative server, is the basis for the selection of the secure 
browser. 

Claim 16 requires that "the secure browser is initiated based on a code associated with the 
secure content" Therefore, it is clear that this distinguishes the secure application of Winneg et 
al., which is initiated before any content (secure or otherwise) is requested, and thus could not be 
initiated based on a code associated with the secure content. 

If this will render the claims allowable, and avoid need for appeal or RCE, Applicants 
will agree to amend claims 1 and 9 to include the subject matter of claims 15 and/or 16. 

REJECTION OF CLAIMS 5 AND 21 UNDER 35 U.S.C. § 103(A) 
In a typical computer system, it is not the browser which converts "text information" to 
"graphic objects"; rather, there is a display driver system separate from the application, which 
receives the source information to be displayed, and then formats it for presentation. Therefore, 
similar to the architecture of Chang et al., the rasterizer services a plurality of applications, and is 
separate therefrom 
CLAIM 5. 

Claim 5 is distinguished at least on the same basis as claim 1 . 

In addition, it is noted that claim 5 provides a different configuration from Chang et al, in 
which the rasterizer (conversion from text information to a graphic object) is part of the secure 
browser process, i.e., "the secure browser renders text information as graphic objects." 
Therefore, Winneg et al, US 7,069,586 and Chang et al., US 2002/0097416 are believed 
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distinguished. In particular, it is not believed that Chang et al. disclose an application-level 
rasterizer, but rather a rasterizer that services all applications on a device, and therefore is 
distinguished from claim 5 which requires that the secure browser, an application, perform the 
conversion. 

CLAIM 20. 

Claim 20 is distinguished at least on the same basis as claim 9. 

In addition, it is noted that claim 5 provides a different configuration from Chang et al, in 
which the rasterizer (conversion from text information to a graphic object) is part of the secure 
browser process, i.e., "the secure browser renders text information as graphic objects." 
Therefore, Winneg et al., US 7,069,586 and Chang et al., US 2002/0097416 are believed 
distinguished. In particular, it is not believed that Chang et al. disclose an application-level 
rasterizer, but rather a rasterizer that services all applications on a device, and therefore is 
distinguished from claim 20, which requires that the secure browser, an application, perform the 
conversion. 

Therefore, it is respectfully requested that the application is allowable. 

Respectfully submitted, 
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